Web三维GIS性能瓶颈元凶！

随着WebGL的逐渐成熟，Web端逐渐成为了GIS可视化的主战场。不同于客户端，Web端首先需要解决网络数据传输以及顾及好前端浏览器在资源上的使用限制，比如渲染上chrome的v8对于内存的使用在32位系统上的最大限制是1G，64位系统上的最大限制是4G，而传输上更是需要视网络情况而定了，目前大多数大型Web3D应用还难以做到在互联网上流畅访问，所以这也成为了一个类似的伪问题，理论上你可以在任何互联网到达的地方使用到系统，但在实际中需要有前提条件比如：第一、足够的带宽；第二、足够好的硬件支持，这条件显然并不比安装个插件或者下载个应用更轻松，前端有限制，工程师们就开始使用后段的技巧去解决这个问题。

1.Web三维大后端

越来越多的厂商意识到整体上收费是不友好的，现在市面上大多数的产品都是前端免费甚至开源，只在后端上进行收费，也有的整体上都以SaaS服务的方式提供，可以这么操作的原因在于对于平台厂商而言核心的技术在后端，也就是我前面多篇文章提到的三维瓦片的构建，所以大多数的方案都开始在后端发力，比如如何在后端构建数据集以及如何将这个数据集构建的更好等，总体来说三维系统从数据到系统开发的基本的流程如下：

2.离散化元凶

如上这个方法已经成为了主流的技术方案，成熟的产品也比较多，但是细细思考整个流程其实总是感觉有些问题，体现在如下几个方面：

1、建模平台和开发平台是分离，相互之间都是独立的体系，二者通过数据格式进行协同；一般情况下数据的生产都是在专业的建模软件中完成，比如对于人工建模的平台就是3d Max，倾斜数据生产的平台就是ContexCapture等，这是从原始数据到模型的构建，这些基础平台是通用平台应用到各行各业去，如果要应用到特定的行业中去还需要借助特定的行业平台来完成专业化的应用，比如模型数据应用到GIS中去就需要导入到GIS平台中，从而进入GIS的技术生态中去，在这之中就存在着数据交换，这个技术交换的过程其实就需要借助公开的交换格式，通用平台将数据导出成交换格式，GIS平台导入交换格式数据，但是这个往往会存在各种各样的问题，比如数据表达方式的不同，从而导致数据丢失，我相信大家也都听说过之前的“共享交换平台”干的就是解决类似的事情。

2、三维数据格式体积总是很大，但是不清楚为什么总是这么大；上面说了平台之间的数据流动是通过公开的交换格式来实现的，但是平台自有数据模型和交换格式的数据模型都是不一样的，因而就存在数据模型的转换，打个比方早期使用DWGDirect.NET来读取DWG这种非公开格式中的数据的时候，如果读取到特定使用数学公式表达的线条的时候，比如贝塞尔曲线，但是目标存储格式却没办法支持这种曲线的表达，比如shapefile文件，为了简单起见直接就调用explode()方法将参数曲线炸开成点串进行转换，显然这样就会导致数据表达不一致同时也会导致数据体积的迅速膨胀。同样的问题其实也存在与三维平台中，在建模软件中我们使用的图元其实是个数学曲面我们可以存储有限个参数就可以实现存储，但是存储都交换格式可能就需要存储三角化后的曲面点、面、索引数据等，比如用的比较多的Wavefront Obj格式，对于一些曲面就需要将曲面离散成基础的图元进行存储，这样就会势必造成体积的膨胀。另外一个层面就是建模人员在建模的时候对于数据体积考虑的不够，在三维要素的构建以及方法的选择的时候都会造成体积的冗余。

3、忽略和前端的能力；Web3D重后端的结果就是强调前端的轻量化，把很多基础的工作都放在后端，比如后端构建数据集的时候就将模型的三角化做完了，数据里面存储的就是离散的面片，这样数据传送到前端就可以直接塞给管线渲染，比如标准Web格式gltf就是直接采用对webgl友好的格式进行数据的存储，它对GL的api非常友好，可以用glBufferData将每个缓冲区加载到GPU中，然后用glVertexAttribPointer解析每个访问器，以绑定到缓冲区中每个顶点元素的位置，但是这样势必也是会加大一些数据的体积，现代浏览器的内核的能力现在也是越来越强，比如谷歌的V8，可以将适度的解析工作放到前端来完成。

总结下来就是跨平台导致的数据离散和冗余，造成三维数据体积出现膨胀，增加了Web三维的难度，数字城市阶段其实也有过大面积的三维数据生产，但是这个阶段三维的兴起其实是由于基于大数据以及物联网的“数字孪生”概念的兴起，所以现阶段的三维其实对于数据本身的地物的真实性关注的不多，反而更加关注机遇三维数据和专题数据的融合可视化，从而实现双赢，这个双赢的概念在于GIS借助传感器数据实现三维数据的升维，传感器借助三维从而解决自己本身数据单一、场景单调的问题。

基于上面的分析，现在就有一种思路就是将建模和可视化集成到一体化平台，从而消除所有的中间环节，如下图所示。而这样的平台在建模层面上通过接口组件以及行业的组件的组合从而在前端就构建出可以满足数据可视化要求的三维模型，这样的三维模型在建模之初只是为了满足简单非真实三维模型的建模，而更加关注模型之间的关联以及附着在模型之上的数据表达效果，从而更加专注，更加能够符合当下趋势对于GIS可视化的要求，同时通过这样的建模手段得到的简单模型全部是在前端构建以及渲染完成，可以最大程度的降低模型的传输成本，可以在前端得到非常流畅的使用体验。一味的追求真实，从而使用的后端化简可视化手段，目前在我看来是一种逐渐失去生命力的手段，与发展的目标渐行渐远。

3.参数化建模

参数化建模其实并不是一个新鲜的词汇，在目前这个背景下，前端建模通过参数化表达其实是非常直接的选择，也有很多成熟的案例，其实说到参数化建模其实和现在数据和样式分离的方式建模是一脉相承的，比如mapbox，比如div+css这些都是一个数据和样式分离的案例，其实当Esri也收购过一个产品叫CityEngine，这个软件是基于规则从而实现的快速建模，但是在当时数字城市以PC端为主要战场的环境下迟迟没有发展起来。

那什么是参数建模？参数化设计过程是指从功能分析到创建参数化模型的整个过程。参数化建模是参数化设计的重要过程，主要包含如下六个方面：

1、分析组成模型的基本元素，以及各个元素之间的关系。

2、分析自由参数与哪些元素有关，如何保证只有参数的自由变化。

3、确定模型主特征及所有的辅助特征。

4、利用表达式编辑器，按照自由参数对部分表达式进行分析。

5、确定特征创建顺序，并进行模型的创建。

6、更改各个自由参数的值，验证模型的变化是否合理。

其实无论是规则、样式还是参数其实都是一个中心思想就是通过简单的数学表达来替代目前滥用的离散数据表达，我相信在web端无论是可交互的软件平台还是开发框架，参数化简单模型都是一个重要的趋势。

---